Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-125

Text File | 1995-12-31 | 113.0 KB | 3,110 lines | [TEXT/R*ch]

C.S.M.P. Digest             Thu, 30 Nov 95       Volume 3 : Issue 125

Today's Topics:

        Best Balloon Utility??
        COMPONENTS don't seem to work in DRIVERS (Apple, why?)
        Can't lock directory using HSetFLock?
        Game Network Model
        Help How to draw Japanese Text by GX.
        Hierarchical Menus in Apple Menu
        How do I patch SFGetFile (or packages in general)
        How do you get to use the utility backdrop as used by find file?
        Mac Texture Mapping code needed
        OpenDoc is here (for the Mac!!!
        Pixel doubling speed note!
        Std Template Library Book
        VBL Syncing Solution and problems.
        Where to put temp files?
        [Q] Volume type information available?
        [Q] _PrimeTime crashes?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Ben Hellstrom)
Subject: Best Balloon Utility??
Date: Thu, 09 Nov 1995 08:32:46 -0500
Organization: jaguNET Access Services

Any opinions on the "best" balloon creation/editing utilities??

--
Ben Hellstrom
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John C. Daub)
Date: Mon, 13 Nov 1995 12:37:55 -0600
Organization: Texas A&M University

In article <[e-mail]>,
[e-mail] (Ben Hellstrom) wrote:

> Any opinions on the "best" balloon creation/editing utilities??

well, if i remember right, there are a bunch of options...

I think there is a dedicated application out there to help write Ballons,
I thin, it's called BallonWriter or something, but i can't remember.

Also, Resourcer works nicely (from what I hear) at helping to write balloons,
and I even think that SC++'s Visual Architect can do Balloons.

Then, if you have CodeWarrior 7, Peter Lewis wrote a plug-in compiler for
CW7 (won't work with anything less) that does balloon help compiling.  I
haven't used it yet, but I've looked it over and it seems pretty straight
forward and easy (tho I've not really had the chance yet to evaluate it)
and only $20 shareware.  You can get this from any Peter Lewis ftp site.

hope that helps!

--
* John C. Daub, aka Hsoi    | mailto:[e-mail]                         *
* Grad Student, Lab Manager | WWW URL: http://http.tamu.edu:8000/~jcd7106/ *
* Self-proclaimed Mac Guru  | Department of Speech Communication           *
* Will program for food.    | Texas A&M University, USA                    *
* "Your future is whatever you make it, so make it a good one" - Doc       *

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Thu, 16 Nov 1995 17:10:02 +0800
Organization: Stairways Software

In article <[e-mail]>,
[e-mail] (Ben Hellstrom) wrote:

>Any opinions on the "best" balloon creation/editing utilities??

Resourcerer or my Balloon Help Compiler plugin for Metrowerks
CodeWarrior.  There isn't really any other choices except Rez or ResEdit
(there is a completely broken program from Apple called Balloon Writer
which hopefully is no longer on the price list).

Enjoy,
   Peter.
--
Web: <http://www.share.com/peterlewis/>
FTP: <ftp://ftp.share.com/pub/peterlewis/>
Email: <mailto:[e-mail]>

---------------------------

>From ËÕ†ÖØâåæf (Steven T. Roussey)
Subject: COMPONENTS don't seem to work in DRIVERS (Apple, why?)
Date: 10 Nov 1995 15:48:46 GMT
Organization: University of California, Irvine

I've spent way too much time trying to figure this one out. Any help is

*greatly* appreciated.

I'm writing a device driver that uses a component and the component
manager to do the actual transfers of data. In my driver I save the A4
world so I can use it in my callbacks. I also create and save a
componentInstance in the Open call. The A4 world and the
componentInstance are the same value across calls to the driver (I
check inside and manually in the debugger).

The component manager chokes and says the componentInstance is not
valid across calls to the driver. That is, it works in the Open call,
but when I use it in Prime, Close etc it doesn't work. Same value, same
A4, and I never close the instance.

It does kinda work if I Open and Close the instance in every call, but
that is way to much overhead. And I'm scared of having to do this in
every callback.

What's going on here? Is there something about the Device Manager the
screws up the Component Manager? Please help. Thanks.

-steve-


                                ---------------------------------------
                                |           Steven T. Roussey         |
                                |     mailto:[e-mail]     |
                                |  http://www.eng.uci.edu/~sroussey/  |
                                ---------------------------------------

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 12 Nov 1995 01:05:18 GMT
Organization: University of Michigan

 > The component manager chokes and says the componentInstance is not
 > valid across calls to the driver. That is, it works in the Open call,
 > but when I use it in Prime, Close etc it doesn't work. Same value, same
 > A4, and I never close the instance.
 >
 > [...]
 >
 > What's going on here? Is there something about the Device Manager the
 > screws up the Component Manager? Please help. Thanks.

When you register and open a component, the Component Manager ties that
component to the calling application. When you send the Open call, that
app gets the component instance, and all others are disallowed.

What you need to do is register the component globally, so that your
driver can call the component from whichever context it comes in from.
(You may also need to restore the home A5 world, but I don't have my
reference at hand, so I don't know for sure.)

Good luck,

Matt

+++++++++++++++++++++++++++

>From ËÕ†ÖØâåæf (Steven T. Roussey)
Date: 12 Nov 1995 18:10:59 GMT
Organization: University of California, Irvine

> > When you register and open a component, the Component Manager ties that
> component to the calling application. When you send the Open call, that
> app gets the component instance, and all others are disallowed.
>
> What you need to do is register the component globally, so that your
> driver can call the component from whichever context it comes in from.

Ahhh... Thanks!

OK, now two questions,

1) Will making the Open call at boot time cause it to be global? (I'm
not doing this right now, but I will have to soon anyhow).

2) Just how do I register the component globally?

-steve-

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 12 Nov 1995 23:55:32 GMT
Organization: University of Michigan

 > 1) Will making the Open call at boot time cause it to be global? (I'm
 > not doing this right now, but I will have to soon anyhow).

I don't know about that, since I have never tried. However, you should
remember that the Component Mgr is built-in to System 7.1, but that for
System 6.0x and 7.0x it is only loaded as part of QuickTime.  You will
need to make arrangements to license it (its free!), and to load your
components *after* QuickTime has loaded.

 > 2) Just how do I register the component globally?

Check out the documentation for the following functions, which are used
to load and "register" the component resources before you "open" them:
[From MPTA]

        pascal long RegisterComponentResourceFile(short resRefNum, short global);

        pascal Component RegisterComponent(ComponentDescription *cd,
                ComponentRoutine componentEntryPoint, short global,
                Handle componentName, Handle componentInfo, Handle componentIcon);

        Where global is a set of flags that control the scope of component
        registration. You can use these flags to specify a value for the global
        parameter:

        registerCmpGlobal = 1;
                Specify this flag to indicate that this component should be made
                available to other applications and clients as well as the one
                performing the registration. If you do not specify this flag,
                the component is available for use only by the registering
                application or component (that is, the component is local to the
                A5 world of the registering program).

        ...


Enjoy,
Matt

+++++++++++++++++++++++++++

>From [e-mail] (Joe Zobkiw)
Date: Wed, 15 Nov 1995 13:31:19 -0500
Organization: Datawatch Corporation

If you're writing a Component you should really be reading INSIDE
MACINTOSH chapters on COMPONENTS for complete information. Guessing isn't
going to help you.

---------------------------

>From [e-mail] (Bekiares Tyrone Drew)
Subject: Can't lock directory using HSetFLock?
Date: 10 Nov 1995 05:55:25 GMT
Organization: University of Illinois at Urbana

Okay, why won't this work?

I want to set the locked bit for a directory using HSetFlock...

here's my code:

vol_name = GetString(128);

if (vol_name != NULL) {
        HLock((Handle)vol_name);
        err = GetVRef (*vol_name, &vref);
        err = FindFolder(kOnSystemDisk,'macs',0,&tvref,&ddir);

        pblock.dirInfo.ioNamePtr = filename;
        pblock.dirInfo.ioVRefNum = vref;
        pblock.dirInfo.ioFDirIndex = -1;
        pblock.dirInfo.ioDrDirID = ddir;
        err = PBGetCatInfo (&pblock, false);

        err = HSetFLock(tvref,2,pblock.dirInfo.ioNamePtr);
        HUnlock((Handle)vol_name);
}

The call to err = HSetFLock(tvref,2,pblock.dirInfo.ioNamePtr); always
returns '-35' : no such volume, '-42' : file not found, and '-5000' afp
access denied depending on what combination of params I give the call..

If I use

err = HSetFLock(tvref,ddir,pblock.dirInfo.ioNamePtr);

than I always get a '-43'...

if I use 2 (root directory) than I always get -35..

and I once got a -5000... can't remember how..

IM says you can use this call to lock directories, but dosen't specify
how you should give the dirID and name accordingly..

thoughts?

Thanks!
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 14 Nov 1995 04:33:13 -0500
Organization: America Online, Inc. (1-800-827-6364)

Bekiares Tyrone Drew wrote:
>I want to set the locked bit for a directory using HSetFlock...
>
>here's my code:
(bunch of stuff omitted)
>IM says you can use this call to lock directories, but dosen't
>specify how you should give the dirID and name accordingly..

You can't lock folders on all volumes. To determine if a volume supports
locking of folders, call PBHGetVolParms and check the bHasFolderLock
volume attribute bit. If it's set, you can lock or unlock folders.

On local HFS volumes, the bHasFolderLock volume attribute bit is set only
when the File Sharing server or AppleShare server is running. Remote
AppleShare volumes always have the bHasFolderLock volume attribute bit
set.

So, that's very likely the problem you're seeing.

The volume reference number, parent directory ID, and name you pass to
HSetFLock should follow the standard File Manager rules. There's a nice
table (Table 2-10) on page 2-35 of "Inside Macintosh: Files" that shows
how the different combinations of vRefNum, dirID and fileName (or
directoryName) are interpreted by the File Manager. You might also want to
review the section "Identifying Files, Directories, and Volumes" that
starts on page 2-23 of IM:Files.

- Jim Luther

---------------------------

>From [e-mail] (Steve Taylor)
Subject: Game Network Model
Date: 4 Nov 1995 14:44:23 -0700
Organization: Utah Valley State College, Orem, Utah


Hi.  Networked games are basically my reason for living, and I've written
several, but my current project is my first attempt at an arcade-speed
networked game.

I'm having trouble figuring out how to get good performance out of
appletalk for >2 players.  Using an existing library I had for
using PPCToolbox, I built my basic game, and it worked great for
two players.  But, as soon as I added a third player, the game
became pretty jerky, running 15 frames or so before freezing for
half a second and continuing.

I'm doing asynchronous reads and writes, (using polling for completion,
not callback routines.  I'm scanning the keyboard instead of calling
GetNextEvent, so my polling routines should get called pretty
frequently with no long time between).  Also, this is a client-server
model, with the app "hosting" the game creating a server port and
its own client port, and with the other app joining the game with
just a client port.

Presumably, the problem is that the server is happily reading and
writing data to its own node and the other node with no problems,
but when I add a third player, it can't send the data simultaneously,
so one message getting written out has to wait for the other to
finish, etc.?  This is assuming the message-to-self part is
fast enough to have no effect.

Can anyone suggest a way for me to get a good smooth rate sending
messages to multiple nodes?  In this case, the server is always
sending identical data to the client nodes, if this helps.

Then, I wrote an ADSP class to replace the PPCToolbox class I was using,
and the game's slower even in 2-player mode.  Maybe I just haven't
done enough optimizing, but should using ADSP directly be faster than
using PPCToolbox?

What protocol do games like Armor Alley use?  Even with 4 players, this
game really cruises on a fast machine.  I know one player hosts a
game, but underneath do they use a client-server model or some
peer-to-peer model?

And, while we're on the subject, why can my application talk to itself
with PPCToolbox but when I try to establish a connection to a
connection listener in the same application with ADSP, I get an error?
(I'm getting -1277, I think, but only on the side that requests the
connection.  The connection listener thinks the connection attempt
succeeded.  Sorry, it's been a few weeks since I played with this.)
I am setting the SelfSend flag.

Thanks very much for any advice, and a belated "Wahoo!" for the creation
of this group.


--
-- Steve Taylor ([e-mail]  or  [e-mail])
--
--  "Ha Ha," said Eeyore bitterly.  "Merriment and what-not.
--  Don't apologize.  It's just what *would* happen."

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 5 Nov 1995 12:03:02 GMT
Organization: Helsinki University of Technology

In article <47gmrn$[e-mail]> [e-mail] (Steve Taylor) writes:
>I'm having trouble figuring out how to get good performance out of
>appletalk for >2 players.  Using an existing library I had for
>using PPCToolbox, I built my basic game, and it worked great for
>two players.  But, as soon as I added a third player, the game
>became pretty jerky, running 15 frames or so before freezing for
>half a second and continuing.

>I'm doing asynchronous reads and writes, (using polling for completion,
>not callback routines.  I'm scanning the keyboard instead of calling
>GetNextEvent, so my polling routines should get called pretty
>frequently with no long time between).  Also, this is a client-server
>model, with the app "hosting" the game creating a server port and
>its own client port, and with the other app joining the game with
>just a client port.

I'm doing something quite similar: a networked arcade game that allows
several players, uses the PPCToolbox with a client/server system and
creates a virtual star topology by passing all messages through the server.

For two players, this means two packets of data for each frame (plus
hidden overhead from the PPCToolbox). For three players, if information
from each player is sent separately, it means six packets of data
for each frame. For four players, it would twelve packets of data
and so on until at six players, you are sending 30 packets of data.

LocalTalk is quite slow, so supporting even just a few players can
be a problem unless you are really careful.

>Then, I wrote an ADSP class to replace the PPCToolbox class I was using,
>and the game's slower even in 2-player mode.  Maybe I just haven't
>done enough optimizing, but should using ADSP directly be faster than
>using PPCToolbox?

I think they should be about the same, since PPCToolbox uses ADSP and
adds only a few bytes extra that you can actually use to transmit
data. PPCToolbox has the advantage of offering you a user interface
for connecting to the server, so it is an excellent choice for almost
any kind of networked applications over AppleTalk.

>What protocol do games like Armor Alley use?  Even with 4 players, this
>game really cruises on a fast machine.  I know one player hosts a
>game, but underneath do they use a client-server model or some
>peer-to-peer model?

I'm just guessing, but I think most games uses DDP and possibly even
DDP (or if they are totally crazy, ALAP) broadcasting. The problem
with DDP is that it doesn't provide resending of lost packets. You
have to do it yourself (ouch).

The problem with DDP broadcasts is that while they do work, you can't
be guaranteed that they will work. The problem is that if you have
two machines using DDP broadcasts, one might crash the other one.
It's because in order to be able to do DDP broadcasts, all players
have to use the same DDP socket number and no one else should be
using them. To be able to use the same socket number, you have to
use the range of "experimental" socket numbers (from 64 to 127).
Apple forbids the use of these sockets for shipping products,
because if two applications happen to use the same one, they will
be sending incompatible data to each other, possibly causing a
crash. (Ouch!)

Unfortunately it is hard to beat the advantages of broadcasting,
since instead of the virtual star network, where you have to
transmit at least 2n packets (or n * (n-1) data), you get away
with n packets for n players.

>And, while we're on the subject, why can my application talk to itself
>with PPCToolbox but when I try to establish a connection to a
>connection listener in the same application with ADSP, I get an error?
>(I'm getting -1277, I think, but only on the side that requests the
>connection.  The connection listener thinks the connection attempt
>succeeded.  Sorry, it's been a few weeks since I played with this.)
>I am setting the SelfSend flag.

Maybe there's a problem with ADSP self sending? PPCToolbox will bypass
networking protocols to talk to a local application, so ADSP is not
involved.

>Thanks very much for any advice, and a belated "Wahoo!" for the creation
>of this group.

I think the start has been quite promising. I feel like I'm revealing
quite a few trade secrets here, but if we all do it, I will not feel
quite that bad about it, because I might actually learn something that
might save me some headaches later.

- --

Here comes the good part of this article (I hope).

PPCToolbox and localtalk are quite fast enough to support a real time
arcade game with at least three to four players. I probably went
through the same problems you had. In fact, I was getting bad results
even with two players, when the other player was a slower machine that
couldn't keep pace.

The important thing is that you should make the timing requirements
loose enough so that the data has the longest possible time to travel
between the machines.

Assuming you copy keyboard and mouse (or joystick) information between
machines and run identical programs on each machine (the way Marathon
works), you'll end up waiting a long time, if you send the data you
need at the exact moment that the other machines need it. The key is to
send this information as early as possible. That way you will use the
full bandwidth that LocalTalk has to offer you. Also keep in mind that
it is very hard to keep several machines sychronized exactly, so allow
some slack in the timing too.

Even this will only work for a couple of players on LocalTalk if you
are replicating a lot of packets with your virtual star network (as I
am). You could of course make the server wait for the information from
all other machines, combine that into a single buffer and send this
buffer back to the other machines.

In the case of four players (one of which is the server), the server
would have to wait for three packets, combine them into one _big_
packet and send this packet back to the three clients. You end up
sending three small packets and three big (4 times bigger) packets, but
you probably save quite a bit of bandwidth because you send fewer
packets (but the saving is all in the overhead).

Unfortunately collecting and combining will work against you if you
want to have very loose timing, because now the data transmission is
very hard to spread over a longer period of time and the machines tend
to run too exactly in synch. Also, this architecture makes no sense at
all when you start using a protocol that allows multicasting or
broadcasting.

So, what could I do then? I didn't touch the PPCToolbox stuff, but I
wrote additional code outside my main network transport classes to
implement DDP and DDP broadcasting. Since there are obvious dangers and
compatibility problems, the user can turn off these parts of the game
and just use the more compatible stuff. In fact, I only use the DDP
parts for really time critical frame information.

Remember the problem with DDP broadcasts? You'll actually be getting
data from all over the net and if two simultaneous games are running in
the same network, you'll receive all their data as well. It's like
listening to several radio stations at the same time and some of them
are not even in your own language.

Fortunately since you are broadcasting to the other nodes as well, you
know all their network addresses and sockets and the packet header
contains enough information so that you can reconstruct an address
block data structure. If the sender is not on your list of friends, you
just ignore the data.

Of course you have to remember that DDP broadcasts only reach one net
at a time, so you may not get away with sending just one broadcast
packet.

Writing DDP protocol handlers is one of the harder tasks that the
Macintosh has to offer you, so good luck. Inside Macintosh has almost
complete sample code. You'll need a multiple net network to test the
code too (or at least Ethertalk) in order to test how your code handles
long packet headers and a very simple localtalk network to test how
your code works with short packet headers.

When DDP packets are lost, one or more machines are left waiting on the
net. That's when I use the PPCToolbox again to ask for the lost data.
This is much more convenient than trying to write my own protocol that
uses DDP.

To recap, here's a quick list of things you should check you are doing
correctly:

        1) Allow the machines to be only loosely in synch.

        2) Send needed data as early as possible so that it has time to
        travel.

        3) Use broadcasting if you still have problems after 1 and 2.

        4) Allow the user to choose what protocols are used.

Due to network latency, networking algorithms that require machines to
run in synch (such as sending keyboard/mouse information) will not run
well over longer distances. Such is life in a relativistic world.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Sun, 05 Nov 1995 09:21:51 -0700
Organization: BW Software

In article <47i95m$[e-mail]>, [e-mail] (Juri Munkki) wrote:

[snip]

>
> I'm just guessing, but I think most games uses DDP and possibly even
> DDP (or if they are totally crazy, ALAP) broadcasting. The problem
> with DDP is that it doesn't provide resending of lost packets. You
> have to do it yourself (ouch).

     Sometimes it isn't worth it to resend packets, IMHO.  Many of the
games that I've played on the 'net have excessive problems with resolving
lost packets.  When they try to fix this, the result is usually complete
chaos, or at least interrupted/choppy gameplay.

     I think a good suggestion came from one of the authors (or was it
just one author?) of Spectre Supreme, which if I remember correctly is on
the CDs that accompany "develop".  It basically stated that by saving some
extra information about the tanks of other players (such as velocity and
direction) the position of a player could be more or less guesstimated.
So for example, if player 2 is having some sort of network trouble and
hasn't "called in" for up to 30 ticks, there shouldn't be much of a
problem, the host machine (or maybe each player's machine...I need to read
that article again ;) will compute the position of player 2 based on
direction and velocity.  The down sides to this are that there will be
more overhead (more information), and obviously this won't work if the
network lag is too great.

> The problem with DDP broadcasts is that while they do work, you can't
> be guaranteed that they will work. The problem is that if you have
> two machines using DDP broadcasts, one might crash the other one.
> It's because in order to be able to do DDP broadcasts, all players
> have to use the same DDP socket number and no one else should be
> using them. To be able to use the same socket number, you have to
> use the range of "experimental" socket numbers (from 64 to 127).
> Apple forbids the use of these sockets for shipping products,
> because if two applications happen to use the same one, they will
> be sending incompatible data to each other, possibly causing a
> crash. (Ouch!)
>
> Unfortunately it is hard to beat the advantages of broadcasting,
> since instead of the virtual star network, where you have to
> transmit at least 2n packets (or n * (n-1) data), you get away
> with n packets for n players.
>

     Am I correct in assuming that there's still no way to write a
PowerMac native DDP socket listener?  I've seen this question asked a few
times, and the only answers I've read point to creating a 68k code
resource that's called by the native code.  There *must* be a better
alternative to this.

--
"Nothin' like a fried 'nanner sandwich..."
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Steve Taylor)
Date: 5 Nov 1995 14:53:30 -0700
Organization: Utah Valley State College, Orem, Utah

Thanks Juri and Eric, for very informative responses.

Eric A. Drumbor ([e-mail]) wrote:

:      I think a good suggestion came from one of the authors (or was it
: just one author?) of Spectre Supreme, which if I remember correctly is on
: the CDs that accompany "develop".  It basically stated that by saving some
: extra information about the tanks of other players (such as velocity and
: direction) the position of a player could be more or less guesstimated.
: So for example, if player 2 is having some sort of network trouble and
: hasn't "called in" for up to 30 ticks, there shouldn't be much of a
: problem, the host machine (or maybe each player's machine...I need to read
: that article again ;) will compute the position of player 2 based on
: direction and velocity.  The down sides to this are that there will be
: more overhead (more information), and obviously this won't work if the
: network lag is too great.

I've heard of this (probably you read it in the Game Developer's Handbook
on the Apple Developer CD?) and I have a question about it:

What do you do with one player performs some action that requires
immediate verification from the server, like stepping on a health-pack.
This player can't assume it suceeded (since the pack may have timed out
or been picked up / destroyed by someone else or something) so does
he just freeze up until the server acknowledges him?

Juri says:

: > The problem with DDP broadcasts is that while they do work, you can't
: > be guaranteed that they will work. The problem is that if you have
: > two machines using DDP broadcasts, one might crash the other one.
: > It's because in order to be able to do DDP broadcasts, all players
: > have to use the same DDP socket number and no one else should be
: > using them. To be able to use the same socket number, you have to
: > use the range of "experimental" socket numbers (from 64 to 127).
: > Apple forbids the use of these sockets for shipping products,
: > because if two applications happen to use the same one, they will
: > be sending incompatible data to each other, possibly causing a
: > crash. (Ouch!)

OK, so what you're saying is that this would be a really cool way to
do a network game and but Apple says no?  Lame...

Any idea if OpenTransport will be enough of a rewrite to provide
broadcasting at some level?

Thanks.

--
-- Steve Taylor ([e-mail]  or  [e-mail])
--
--  "Ha Ha," said Eeyore bitterly.  "Merriment and what-not.
--  Don't apologize.  It's just what *would* happen."

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Sun, 05 Nov 1995 16:34:18 -0700
Organization: BW Software

In article <47jboq$[e-mail]>, [e-mail] (Steve Taylor) wrote:

[snip]

> I've heard of this (probably you read it in the Game Developer's Handbook
> on the Apple Developer CD?) and I have a question about it:
>
> What do you do with one player performs some action that requires
> immediate verification from the server, like stepping on a health-pack.
> This player can't assume it suceeded (since the pack may have timed out
> or been picked up / destroyed by someone else or something) so does
> he just freeze up until the server acknowledges him?

     Personally, I'd make it a sort of "request" from player Mac to server
Mac.  The health/bonus/whatever won't be counted until confirmation from
the server is received.  In the meantime, the player just keeps playing.
The server can take the request, look at the status of this item, and take
whatever actions are appropriate.  This would work best if the player's
Mac wasn't expecting a confirmation or denial....if it receives a packet
from the server that says "here's a bonus, use it" then the player Mac
acts accordingly.  In other words, it won't be searching for some kind of
special packet, and the server won't be wasting network bandwidth telling
the player that the item wasn't obtained.

     The only problem with this would (of course) be excessive lag time.
If the character of player 2 is almost dead, and the health bonus is
needed in 1 second because in two seconds a missle is going to make
contact......lag time would spell doom for player 2, and unfairly so.  The
only alternative is to allow the player's computer to make the judgement,
which could mean that several players could get the same item because the
server wasn't fast enough to send an update to the players.  It's really
dependent on the game IMHO, you'll need to decide which is more fair or
more entertaining to the players.

--
"Nothin' like a fried 'nanner sandwich..."
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 6 Nov 1995 13:40:53 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Eric A. Drumbor) writes:
>     Sometimes it isn't worth it to resend packets, IMHO.  Many of the
>games that I've played on the 'net have excessive problems with resolving
>lost packets.  When they try to fix this, the result is usually complete
>chaos, or at least interrupted/choppy gameplay.

This depends on how you implement networking. In a game where there are a lot
of automatons that react to the actions of the players, you either have to
guarantee that their actions are the same on all machines or that information
is transmitted over the network. Usually it is just easier to run the exact
same process on each machine and use the network as a sort of virtual joystick
port. If there are bugs in the game or information is altered or lost, the
games on each machine will start to diverge.

As I understand it, Marathon uses the "virtual joystick interface" approach
and it had some bugs in the early versions.

>     I think a good suggestion came from one of the authors (or was it
>just one author?) of Spectre Supreme, which if I remember correctly is on
>the CDs that accompany "develop".  It basically stated that by saving some
>extra information about the tanks of other players (such as velocity and
>direction) the position of a player could be more or less guesstimated.

This is a good approach when the players are likely to be far apart
geographically, because then you have to deal with long delays. You
have to accept that each player may have his/her own view of what
happened in the world. The rules for missile hits and such have to
be very clear, since you can't have a robot exploding on one screen
and surviving on another one. (The owner of the object has the final
say.) Of course then you have a lot of objects that need owners and
you have to keep sending this information over the network.

>direction and velocity.  The down sides to this are that there will be
>more overhead (more information), and obviously this won't work if the
>network lag is too great.

All information has to be time stamped so that data can be extrapolated
correctly.

>     Am I correct in assuming that there's still no way to write a
>PowerMac native DDP socket listener?  I've seen this question asked a few
>times, and the only answers I've read point to creating a 68k code
>resource that's called by the native code.  There *must* be a better
>alternative to this.

Check the latest Appletalk headers. I saw something there, but it looked
quite complicated and not really relevant to the 68K code that I was
writing.

Should we try to agree on a de facto standard for the use of DDP
broadcasts in games? Choose a socket number that we all use for this
purpose and check the sender address before accepting the packets.
(This only works as long as a single copy of a game is running on
a machine, since sockets can not be shared.)

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 6 Nov 1995 14:43:29 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Eric A. Drumbor <[e-mail]> wrote:

>     Sometimes it isn't worth it to resend packets, IMHO.

Yes. Try to design your client so that it works even if it has to skip
a few packets. That should save tremendous time and effort.

>     Am I correct in assuming that there's still no way to write a
>PowerMac native DDP socket listener?

As far as I know, there is none. However, as long as AppleTalk is
emulated, you *don't* want to write one; the double mode switch will
cost you a lot of time every time you receive a packet. So, just keep
your old 68K listener. By the way, using the old (non-preferred) DDP
interface it is possible to receive DDP packets without writing a
listener (you have to poll the parameter block).

--
Francois
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Mon, 06 Nov 1995 08:11:19 -0700
Organization: BW Software

In article <47l396$[e-mail]>, [e-mail] (Juri Munkki) wrote:

[excellent networking info snipped]

> >     Am I correct in assuming that there's still no way to write a
> >PowerMac native DDP socket listener?  I've seen this question asked a few
> >times, and the only answers I've read point to creating a 68k code
> >resource that's called by the native code.  There *must* be a better
> >alternative to this.
>
> Check the latest Appletalk headers. I saw something there, but it looked
> quite complicated and not really relevant to the 68K code that I was
> writing.

     I have to admit that I haven't looked into the networking aspect for
quite a few months.  I took a quick look at IM:Networking yesterday, and
now I'm wondering if it really wouldn't be such a bad idea to try to write
the socket listener in PPC assembly using CW7 and it's function level
assembler.  Wasn't the whole problem with the listener written in PPC asm
due to the fact that register usage wasn't specified?

> Should we try to agree on a de facto standard for the use of DDP
> broadcasts in games? Choose a socket number that we all use for this
> purpose and check the sender address before accepting the packets.
> (This only works as long as a single copy of a game is running on
> a machine, since sockets can not be shared.)

     I think we definitely should try to establish some standards, great
suggestion.  Why not reserve a few sockets?  Like five?  Five sockets
would make allowances for multiple games being played (in the off chance
that is occurring) or allow for a game that uses multiple sockets (some
future game).  There's little chance that someone would be using more than
five games at any given time on their Mac, but just to be safe...  This
would obviously create more work, since the games need to contact each
other (probably via dynamic socket) to agree on which socket to use, but I
wouldn't want to set anything as a standard (ableit de facto) that didn't
have a little breathing room.

     Do we have a faq for this group yet?  If not, we better get something
together.  If we're going to be a little "god-like" we should have a faq
for newcomers....and people who aren't reading this thread...and better
still, people like myself who forget this stuff within a few days :-)

--
"Nothin' like a fried 'nanner sandwich..."
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 6 Nov 1995 17:55:44 GMT
Organization: Helsinki University of Technology

In article <47jboq$[e-mail]> [e-mail] (Steve Taylor) writes:
>Juri says:
>: > The problem with DDP broadcasts is that while they do work, you can't
>: > be guaranteed that they will work. The problem is that if you have
>: > two machines using DDP broadcasts, one might crash the other one.
>: > It's because in order to be able to do DDP broadcasts, all players
>: > have to use the same DDP socket number and no one else should be
>: > using them. To be able to use the same socket number, you have to
>: > use the range of "experimental" socket numbers (from 64 to 127).
>: > Apple forbids the use of these sockets for shipping products,
>: > because if two applications happen to use the same one, they will
>: > be sending incompatible data to each other, possibly causing a
>: > crash. (Ouch!)

>OK, so what you're saying is that this would be a really cool way to
>do a network game and but Apple says no?  Lame...

Well...Apple says that you shouldn't draw directly to the screen, since
it might break. Apple also says that you shouldn't move the mouse cursor
under program control, but several games need to do this.

As in the case of direct screen drawing and mouse motion, Apple explains
what the dangers are and similarly if something like this is implemented
in a game, the safest thing to do is to leave the final say to the user.

In my game, the user has three levels of networking: PPCToolbox only,
DDP based and DDP broadcast based. The user can choose the one that
works best. In most cases, the DDP based method works well enough.

For localtalk networks with a lot of players, the broadcasting version
may have to be used. The only machines it can hurt are ones that
choose to listen to this same socket AND that expect some specific data
format AND do not check where the data is coming from.

My advice is: go ahead and implement DDP broadcasting, but do it right.

(The same goes for direct to screen drawing: if you do it wrong, you
are going to crash quite a few machines.)

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 7 Nov 1995 09:06:11 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Eric A. Drumbor) writes:
>In article <47l396$[e-mail]>, [e-mail] (Juri Munkki) wrote:
>> Should we try to agree on a de facto standard for the use of DDP
>> broadcasts in games? Choose a socket number that we all use for this
>> purpose and check the sender address before accepting the packets.
>> (This only works as long as a single copy of a game is running on
>> a machine, since sockets can not be shared.)

>     I think we definitely should try to establish some standards, great
>suggestion.  Why not reserve a few sockets?  Like five?  Five sockets
>would make allowances for multiple games being played (in the off chance
>that is occurring) or allow for a game that uses multiple sockets (some
>future game).  There's little chance that someone would be using more than
>five games at any given time on their Mac, but just to be safe...  This
>would obviously create more work, since the games need to contact each
>other (probably via dynamic socket) to agree on which socket to use, but I
>wouldn't want to set anything as a standard (ableit de facto) that didn't
>have a little breathing room.

For DDP broadcasts, every machine in the game has to use the same socket
number. So if five sockets are reserved and the one all the other machines
want is taken on one machine, all the machines would have to use the other
socket and the negotiation process could be complicated. In my case, I
would just forget about broadcasting and reserve a regular DDP socket
for the machine where the broadcast socket was not available.

I don't have anything against "reserving" multiple sockets, but I feel
that only one is really needed. Only 64 of these special sockets exist
in any case. Another option would be to ask Apple to give us one of the
first 64 sockets (in the 0-63 range). That would make things a lot
more official and sort of establish a game networking broadcast protocol
of sorts...

>     Do we have a faq for this group yet?  If not, we better get something
>together.  If we're going to be a little "god-like" we should have a faq
>for newcomers....and people who aren't reading this thread...and better
>still, people like myself who forget this stuff within a few days :-)

I think I saw a skeleton for an FAQ among the first articles in this newsgroup,
but I didn't really read it thoroughly.

I'm going to keep any long articles I write archived under my WWW page, so
if someone missed my original answer to this thread, it can still be found
here: http://www.hut.fi/~jmunkki/misc

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Steve Taylor)
Date: 7 Nov 1995 19:37:42 -0700
Organization: Utah Valley State College, Orem, Utah


I think trying to convince Apple to give us a few socket numbers
for sanctioned broadcasting is a great idea.  Perhaps
Eric Klein (the Game Evangelist at Apple) could help with this?
I'm pretty sure his address is [e-mail], if someone
wants to take it upon themselves to bug him about this...

--
-- Steve Taylor ([e-mail]  or  [e-mail])
--
--  "Ha Ha," said Eeyore bitterly.  "Merriment and what-not.
--  Don't apologize.  It's just what *would* happen."

+++++++++++++++++++++++++++

>From [e-mail] (Ingemar Ragnemalm)
Date: 8 Nov 1995 12:42:10 GMT
Organization: (none)

[e-mail] (Juri Munkki) writes:

>I'm just guessing, but I think most games uses DDP and possibly even
>DDP (or if they are totally crazy, ALAP) broadcasting.

I have to ask: why is ALAP "crazy"? Yes, it is limited to AppleTalk only,
it is old, but it has broadcasting built-in. If you accept that the game
you make is standard-Appletalk only, isn't this a pretty easy way to get
broadcasting?

--
- -
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Hugh Fisher)
Date: 9 Nov 1995 09:40:58 +1100
Organization: Australian National University

In article [e-mail],  [e-mail] (Juri Munkki) writes:

> [ munch ]
>
>Should we try to agree on a de facto standard for the use of DDP
>broadcasts in games? Choose a socket number that we all use for this
>purpose and check the sender address before accepting the packets.
>(This only works as long as a single copy of a game is running on
>a machine, since sockets can not be shared.)

  *Multicast*, please, not broadcast. On LocalTalk it doesn't matter
  since AFAIK multicast = broadcast in the implementation. But if you
  broadcast on Ethernet, every host, not just those playing the game,
  has to process a 'packet received' interrupt. This is why Doom is
  so unpopular with network managers. If you multicast, then only the
  the hosts actively listening for that address process the packets.
  (The network may still be saturated with your game traffic, but at
  least nobody can complain that you're slowing down their CPU.)

        Hugh Fisher



+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 9 Nov 1995 09:27:32 GMT
Organization: Helsinki University of Technology

In article <47rblq$[e-mail]> [e-mail] writes:
>  *Multicast*, please, not broadcast.

Show us a way to do multicasting with AppleTalk and we might do it.
Just remember that it has to work with LocalTalk too...

Why? Because it's very hard for you to tell what kind of network you
are sending to. I have tested my game in a network with a mix of
different network types. DDP broadcasting worked on all of them,
because it is part of the AppleTalk protocol.

Part of the reason is also because I happen to like solutions
that work on all platforms. I find it very frustrating if I have
to check for specific hardware and software features before I can
use them. It also makes things a lot more complicated for the
beginners when things like networking are already more complicated
than they need to be.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 9 Nov 1995 15:46:41 GMT
Organization: Helsinki University of Technology

In article <47q8j3$[e-mail]> [e-mail] (Ingemar Ragnemalm) writes:
>I have to ask: why is ALAP "crazy"? Yes, it is limited to AppleTalk only,
>it is old, but it has broadcasting built-in. If you accept that the game
>you make is standard-Appletalk only, isn't this a pretty easy way to get
>broadcasting?

You have to look at the benefits and disadvantages. The only benefit I see
is that there's slightly less overhead involved. The big disadvantage is
that it doesn't travel across network bridges, so you are limited to a
very local network only.

On the other hand, I have used DDP on a net that had one LocalTalk (PhoneNet)
net and two Ethernets. The only thing you have to do is to send a broadcast
to each separate net (as broadcasts are fortunately limited to a single
net).

In other respects, ALAP and DDP are quite similar and the amount of work
involved to use them is the same.

Also, if I remember correctly, some network types do not implement ALAP
at all (I think Apple Remote Access might be one of them).

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Joel L Duerksen)
Date: Tue, 14 Nov 1995 10:06:06 -0500
Organization: Eli Lilly and Company


>   *Multicast*, please, not broadcast. On LocalTalk it doesn't matter
>   since AFAIK multicast = broadcast in the implementation. But if you
>   broadcast on Ethernet, every host, not just those playing the game,
>   has to process a 'packet received' interrupt. This is why Doom is
>   so unpopular with network managers.
unfortunately their FIRST version did use broadcast.  None after that
have.

> If you multicast, then only the
>   the hosts actively listening for that address process the packets.
>   (The network may still be saturated with your game traffic, but at
>   least nobody can complain that you're slowing down their CPU.)
Also unfortunately most networks and routers don't properly
support multicast yet.

---------------------------

>From [e-mail] (Eiji Ikeda)
Subject: Help How to draw Japanese Text by GX.
Date: Fri, 10 Nov 1995 21:55:10 +0900
Organization: (empty)

I can't draw Japanese Text by GX.

My source codes are ...

   gxFont myFont;

   long numJfonts = GXFindFonts (nil, gxFullFontName,
            gxMacintoshPlatform, gxJapaneseScript, gxNoLanguage,
                  strlen ("Osaka"),
                  (unsigned char const *) "Osaka", 1, 1, &myFont);
   aShape = GXNewText (12, (unsigned char const *) "(Kanji Text 12 len)",
         &textPosition);
   SetShapeCommonColor (aShape, blue);
   GXSetShapeFont (aShape, myFont);
   GXDrawShape (aShape);
   GXDisposeShape (aShape);

By this, some unreadable objects are drawn. They are not kanji text.
What Shall I do?

--
Eiji Ikeda
[e-mail]
asciinet: net07199 (alf)
NIFTY: PEA03350

+++++++++++++++++++++++++++

>From [e-mail] (David Opstad)
Date: 12 Nov 1995 15:54:58 -0800
Organization: Apple Computer Inc, Cupertino, CA

In article <[e-mail]>,
Eiji Ikeda <[e-mail]> wrote:
>I can't draw Japanese Text by GX.
>
>My source codes are ...
>
>   gxFont myFont;
>
>   long numJfonts = GXFindFonts (nil, gxFullFontName,
>            gxMacintoshPlatform, gxJapaneseScript, gxNoLanguage,
>                  strlen ("Osaka"),
>                  (unsigned char const *) "Osaka", 1, 1, &myFont);
>   aShape = GXNewText (12, (unsigned char const *) "(Kanji Text 12 len)",
>         &textPosition);
>   SetShapeCommonColor (aShape, blue);
>   GXSetShapeFont (aShape, myFont);
>   GXDrawShape (aShape);
>   GXDisposeShape (aShape);
>
>By this, some unreadable objects are drawn. They are not kanji text.
>What Shall I do?

In order to use the correct mapping, you need to attach an encoding to the
shape, telling it to use the Japanese encoding. Add this line:

GXSetShapeEncoding(aShape, gxMacintoshPlatform, gxJapaneseScript, 0);

That should fix the problem. Also remember that GXNewText takes a character
count, and not a byte count -- by passing 12 in your call, you are telling
GX that you are providing 24 bytes of 2-byte text.

Dave Opstad
GX Line Layout Weenie

---------------------------

>From [e-mail] (molly gilmore-baldwin)
Subject: Hierarchical Menus in Apple Menu
Date: Sun, 12 Nov 1995 22:13:25 -0600
Organization: INS Info Services, Des Moines, Iowa, USA

I apologize in advance.  I remember this subject being discussed in detail
before. However, I tried what I thought had been the recommendation, and
it isn't working for me.

It's the old: I create my menu bar, and I don't get hierarchical menus
under the apple menu (Using Apple Menu Options).  I get my own
hierarchical menu just fine.

System 7.5, Codewarrior 7.

Any help would be appreciated.  Also, if this info is anywhere I could
have found it, I'd like to know where.  Before posting this, I spent quite
a while hunting the net.  Thanks.

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosen)
Date: Mon, 13 Nov 1995 23:10:04 -0500
Organization: The Internet Access Company

In article <[e-mail]>, [e-mail]
(molly gilmore-baldwin) wrote:

>It's the old: I create my menu bar, and I don't get hierarchical menus
>under the apple menu (Using Apple Menu Options).

Make sure you're calling both InitMenus and MaxApplZone at the beginning
of your program.

--Alex

+++++++++++++++++++++++++++

>From [e-mail] (molly gilmore-baldwin)
Date: Tue, 14 Nov 1995 07:46:56 -0600
Organization: INS Info Services, Des Moines, Iowa, USA

In article <axlrosen-1311952310040001@205.161.42.140>, [e-mail]
(Alex Rosen) wrote:

> In article <[e-mail]>, [e-mail]
> (molly gilmore-baldwin) wrote:
>
> >It's the old: I create my menu bar, and I don't get hierarchical menus
> >under the apple menu (Using Apple Menu Options).
>
> Make sure you're calling both InitMenus and MaxApplZone at the beginning
> of your program.
>
> --Alex
Thank you. That was it.

---------------------------

>From "Stephen E. Maas" <[e-mail]>
Subject: How do I patch SFGetFile (or packages in general)
Date: Tue, 14 Nov 1995 05:56:31 GMT
Organization: Maasware Enterprises

I need to patch SFGetFile. How do I go about this? I am not sure how to
pass selector codes with NSetTrapAddress. Is that how it is done? Source
examples would be great, but all I really need is a brief explanation
(if there is one).

Please don't offer alternatives to patching SFGetFile, as there are none
for what I need to do (if there were, I wouldn't be trying this).

Thanks.

--
Stephen E Maas   #   Microsoft Network is prohibited from redistributing
[phone]   #   this work in any form, in whole or in part.
License
[e-mail]   #   to distribute this post is available to Microsoft
for
"Been there,     #   $95.00.  Posting without permission constitutes an
done that."      #   agreement to these terms.
- Apple Computer
  Regarding Windows 95



+++++++++++++++++++++++++++

>From [e-mail] (James W. Walker)
Date: Tue, 14 Nov 1995 20:32:54 -0800
Organization: Nisus Software

In article <[e-mail]>, "Stephen E. Maas"
<[e-mail]> wrote:

> I need to patch SFGetFile. How do I go about this? I am not sure how to
> pass selector codes with NSetTrapAddress. Is that how it is done?

Nope, that's not how it's done.  You patch _Pack3, the trap that
implements Standard File, and your patch looks for the selector code.  So
far as I know, you can't do this in a high-level language.  You also can't
do it PowerPC-native.  So we're talking 68K assembly language.
--
 Jim Walker

+++++++++++++++++++++++++++

>From [e-mail] (Bill Stewart-Cole)
Date: Wed, 15 Nov 1995 20:38:08 -0600
Organization: ZOG

In article <[e-mail]>, "Stephen E. Maas"
<[e-mail]> wrote:

>I need to patch SFGetFile. How do I go about this? I am not sure how to
>pass selector codes with NSetTrapAddress. Is that how it is done? Source
>examples would be great, but all I really need is a brief explanation
>(if there is one).

Speaking to selector traps in general, the only way is to patch the trap
as a whole and pass thru the calls with selectors you don't want to fiddle
with. Preferably as a head-only patch that covers its tracks before
passing thru to the real trap.

>Please don't offer alternatives to patching SFGetFile, as there are none
>for what I need to do (if there were, I wouldn't be trying this).

Are you sure that CustomGetFile is not going to cut it?
--
Bill Stewart-Cole
What is Stewart-Cole Consulting?
Hell if I know. I'll find out when I finish the web page.
Current projected date: 12/1. I'm not saying what year

---------------------------

>From [e-mail] (Thomas Haggie)
Subject: How do you get to use the utility backdrop as used by find file?
Date: 13 Nov 1995 13:04:21 GMT
Organization: Electronics and Computer Science, University of Southampton

Hello;
        I was wondering how to get and use the pattern ( set by option
clicking in the Desktop Patterns control panel ) used by Find File etc.
to use it in my own little Utilities?

                        All help appreciated

                                        -*TOM*-

[e-mail]    http://whirligig.ecs.soton.ac.uk/~tah92/cv.html

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 14 Nov 1995 03:01:24 GMT
Organization: University of Michigan

Thomas Haggie, [e-mail] writes:
 >     I was wondering how to get and use the pattern ( set by option
 > clicking in the Desktop Patterns control panel ) used by Find File etc.
 > to use it in my own little Utilities?

Its just a 'ppat' resource within the System file (like 7.1 or later, I
think). Like the desktop pattern has ID = 16, the util pattern has ID=42
(use ResEdit to find out for certain). Just load the PPAT as normal.

Matt

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 13 Nov 1995 23:08:42 -0800
Organization: Townsend Communications

In article <4890q4$[e-mail]>, Matt Slot
<[e-mail]> wrote:

> Its just a 'ppat' resource within the System file (like 7.1 or later, I
> think). Like the desktop pattern has ID = 16, the util pattern has ID=42
> (use ResEdit to find out for certain). Just load the PPAT as normal.

And as with other System file resources, remember to forget to clean it up
after getting it...the handle you get may be in use by another
process...making it go away is bad form (and leads to bad results).

   --John

--
  "This item is not available because it cannot be removed."
John W. Baxter    Port Ludlow, WA     [e-mail]

---------------------------

>From [e-mail] (Rasmussen/Hugos Family)
Subject: Mac Texture Mapping code needed
Date: Thu, 09 Nov 1995 18:06:14 -0800
Organization: Teleport - Portland's Public Access [phone]

Hello,

I am a slighly experienced mac programmer using CodeWarrior. I need to do
some texture mapping, but no where can I find any code to do it, and I
really don't want to resort to QuickDraw 3D. Can anyone tell me where to
get an idea on how to do this? (e.g. book, source code...)


Thank you very much

+++++++++++++++++++++++++++

>From [e-mail]
Date: Mon, 13 Nov 1995 14:36:52 GMT
Organization: Lexmark International, Lexington, KY

In article <[e-mail]> [e-mail] (Rasmussen/Hugos Family) writes:

   [...]
   I am a slighly experienced mac programmer using CodeWarrior. I need to do
   some texture mapping, but no where can I find any code to do it, and I
   really don't want to resort to QuickDraw 3D. Can anyone tell me where to
   get an idea on how to do this? (e.g. book, source code...)
   [...]

Hi!

     Game Developer magazine has had a running series on texture
mapping. I have found it quite informative.

Anyway,
-Chris

+++++++++++++++++++++++++++

>From [e-mail] (Ken Offer)
Date: Mon, 13 Nov 1995 15:10:47 -0600
Organization: Illuminati Online

Check out "Graphics Gems", edited by Andrew Glassner, published by
Academic Press.  Page 84 describes a convex polygon scan conversion
routine with provisions for texture mapping.  Sadly, it is not a complete
example of texture mapping, and it is written using some very tricky code
which is a clear abomination before all sentient life-forms.

Combine that with a snippet on page 363 from "Principles of Interactive
Computer Graphics" describing the mysterious "w" variable (sometimes known
as "sw") and homogeneous coordinates, and after a few days of
head-scratching and determination you may achieve nervana.


In article <[e-mail]>,
[e-mail] (Rasmussen/Hugos Family) wrote:

> Hello,
>
> I am a slighly experienced mac programmer using CodeWarrior. I need to do
> some texture mapping, but no where can I find any code to do it, and I
> really don't want to resort to QuickDraw 3D. Can anyone tell me where to
> get an idea on how to do this? (e.g. book, source code...)
>
>
> Thank you very much

+++++++++++++++++++++++++++

>From [e-mail] (Chris Hecker)
Date: Tue, 14 Nov 1995 09:55:46 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

>> I am a slighly experienced mac programmer using CodeWarrior. I need to do
>> some texture mapping, but no where can I find any code to do it, and I
>> really don't want to resort to QuickDraw 3D. Can anyone tell me where to
>> get an idea on how to do this? (e.g. book, source code...)

Shameless plug: You might check out my articles in Game Developer
Magazine.  I cover the math behind perspective texture mapping and
provide source code that you could easily port to the mac (you'd just
change the bitmap structure that it draws into).  You'll probably want
the apr/may, jun/jul, and aug/sep issues, and you can order back issues
from [phone].

Chris


---------------------------

>From [e-mail] (Lawson English)
Subject: OpenDoc is here (for the Mac!!!
Date: 7 Nov 1995 18:37:38 GMT
Organization: Primenet [phone]

Point your Web browser to www.info.apple.com (I think). APple just put
out a press release that they are now shipping OpenDoc...

The SDK will be available for ftp by November 10.


--
- -----------------------------------------------------------------------------
Lawson English                            __  __     ____  ___       ___ ____
[e-mail]                     /__)/__) / / / / /_  /\  / /_    /
                                        /   / \  / / / / /__ /  \/ /___  /
- -----------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Will Parker)
Date: 8 Nov 1995 21:32:13 GMT
Organization: Shepard LifeFleet

In article <47o91i$[e-mail]>, [e-mail]
(Lawson English) wrote:

> Point your Web browser to www.info.apple.com (I think). APple just put
> out a press release that they are now shipping OpenDoc...
>
> The SDK will be available for ftp by November 10.
> ...

The same news release states that a CD-ROM version is available on request
by emailing [e-mail], in case you have a lazy modem.

+++++++++++++++++++++++++++

>From [e-mail] (Damon Cokenias)
Date: Sun, 12 Nov 1995 17:13:40 -0800
Organization: Mountain Palace

In article <47o91i$[e-mail]>, [e-mail]
(Lawson English) wrote:

> Point your Web browser to www.info.apple.com (I think). APple just put
> out a press release that they are now shipping OpenDoc...

The more direct route is www.opendoc.apple.com

For information about ODF, the OpenDoc Development Framework (a class
library for building OpenDoc components) check out
www.opendoc.apple.com/odfmain.html

-Damon Cokenias
ODF Team Member

+-----------------------------------------------------------------------+
|   /\    Damon Cokenias                                                |
|  /^^\   [e-mail]                                       |
| /____\  Visit the Mountain Palace at http://www.netgate.net/~cokenias |
+-----------------------------------------------------------------------+

---------------------------

>From [e-mail] (Christoph Bergmann)
Subject: Pixel doubling speed note!
Date: Sat, 04 Nov 1995 23:13:23 +1000
Organization: University of Queensland

here's an interesting and useful one for ppc pixel doubling routines in C:

calculate 8 dst pixels at once as two longs. then store them into two
memory addresses. load them as a double and then store them into the two
consecutive scan-lines..

because vram is "slower" (it seems to be anyway) than dram, the fact of
moving half as many addresses into vram more than makes up for the speed
lost converting to a float..
this speeds things up a lot over moving longs into vram.. (on a ppc7100/80
anyway - might not be so good on a 603?).

any comments..
ChrisB.

+++++++++++++++++++++++++++

>From [e-mail] (Gavin Kistner)
Date: Sat, 04 Nov 1995 16:43:10 -0500
Organization: Image Refinery Productions, Inc.

In article <[e-mail]>,
[e-mail] (Christoph Bergmann) wrote:

>here's an interesting and useful one for ppc pixel doubling routines in C:
[snip]
>any comments..

Do you have any numbers comparing the speed for this?

- Gavin
___________________________________________________________
Gavin Kistner, aka RabYak, aka !Bob          [phone]
<-> Graphics Designer, Image Refinery Productions, Inc. <->
[e-mail]       ftp/finger to phrogz.dorm.duke.edu

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosenberg)
Date: Mon, 06 Nov 1995 19:27:28 -0800
Organization: Hackers Anonymous

In article <[e-mail]>,
[e-mail] (Christoph Bergmann) wrote:

>here's an interesting and useful one for ppc pixel doubling routines in C:
>
>calculate 8 dst pixels at once as two longs. then store them into two
>memory addresses. load them as a double and then store them into the two
>consecutive scan-lines..

Solid tip. That's one of the first things we've shown people in the Game
Kitchens. I'll additionally point out that the doubling routine can make
use of the rlwimi instruction to perform the byte swizzling. Note that CW7
doesn't pick up on the ability to use this instruction, so you'll have to
resort to assembly.

- -------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail]      - Yoyodyne    -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr        - Propulsion  -
-  Palo Alto, CA 94301     -                                - Systems     -
-  [phone]          - Nobody is my employer so       - :-)         -
-  [phone]          - nobody cares what I say.       -             -

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Tue, 07 Nov 1995 06:48:41 -0700
Organization: BW Software

In article <alexr-0611951927330001@17.202.12.160>, [e-mail] (Alex
Rosenberg) wrote:

> In article <[e-mail]>,
> [e-mail] (Christoph Bergmann) wrote:
>
> >here's an interesting and useful one for ppc pixel doubling routines in C:
> >
> >calculate 8 dst pixels at once as two longs. then store them into two
> >memory addresses. load them as a double and then store them into the two
> >consecutive scan-lines..
>
> Solid tip. That's one of the first things we've shown people in the Game
> Kitchens. I'll additionally point out that the doubling routine can make
> use of the rlwimi instruction to perform the byte swizzling. Note that CW7
> doesn't pick up on the ability to use this instruction, so you'll have to
> resort to assembly.

     Speaking of Game Kitchens, where can people find more info on Apple's
Game Kitchens?  Also, are there any transcripts of what went on there?

--
"Nothin' like a fried 'nanner sandwich..."
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Eric A. Drumbor)
Date: Tue, 07 Nov 1995 06:59:25 -0700
Organization: BW Software

In article <alexr-0611951927330001@17.202.12.160>, [e-mail] (Alex
Rosenberg) wrote:

[snip]

> Solid tip. That's one of the first things we've shown people in the Game
> Kitchens. I'll additionally point out that the doubling routine can make
> use of the rlwimi instruction to perform the byte swizzling. Note that CW7
> doesn't pick up on the ability to use this instruction, so you'll have to
> resort to assembly.

     Speaking of Game Kitchens, where can people find more info on Apple's
Game Kitchens?  Also, are there any transcripts of what went on there?




BTW:  Sorry if this was posted multiple times...my news server is having
some problems..

--
"Nothin' like a fried 'nanner sandwich..."
Eric A. Drumbor
[e-mail]                 <http://www.nilenet.com/~ericd/>
BW Software

+++++++++++++++++++++++++++

>From [e-mail] (Robert Barris)
Date: Tue, 7 Nov 1995 08:15:32 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

In article <alexr-0611951927330001@17.202.12.160>,
Alex Rosenberg <[e-mail]> wrote:
>In article <[e-mail]>,
>[e-mail] (Christoph Bergmann) wrote:
>
>>here's an interesting and useful one for ppc pixel doubling routines in C:
>>
>>calculate 8 dst pixels at once as two longs. then store them into two
>>memory addresses. load them as a double and then store them into the two
>>consecutive scan-lines..
>
>Solid tip. That's one of the first things we've shown people in the Game
>Kitchens. I'll additionally point out that the doubling routine can make
>use of the rlwimi instruction to perform the byte swizzling. Note that CW7
>doesn't pick up on the ability to use this instruction, so you'll have to
>resort to assembly.

Fortunately CW7 now has an assembler!! ! :)

As an aside, the key reason this technique works so well is that the writes
which are done to the temporary 8-byte variable generally don't cause any
memory traffic - they hit in the L1 cache (at least they do after the
first such access) and don't go off-chip (writeback cache is Good). Four
bytes in from DRAM, 16 bytes out (a pair of doubles), no other external
memory traffic if it's done right.

Rob Barris
Quicksilver Software Inc.
[e-mail]
* Opinions expressed not necessarily those of my employer *

>From [e-mail] (Christoph Bergmann)
Subject: Pixel doubling speed note!
Date: Thu, 09 Nov 1995 22:39:07 +1000
Organization: University of Queensland

In article <[e-mail]>,
[e-mail] (Gavin Kistner) wrote:

> Do you have any numbers comparing the speed for this?

yeah..

on a ppc7100/80 i am getting
 37 fps using doubles
and
 33 fps using longs

this is a considerable boost considering that my blit routine is taking
only 30% of the execution time.

ChrisB.

+++++++++++++++++++++++++++

>From [e-mail] (Atman Binstock)
Date: 9 Nov 1995 14:17:37 -0500
Organization: Panix

>In article <[e-mail]>,
>[e-mail] (Christoph Bergmann) wrote:
>
>here's an interesting and useful one for ppc pixel doubling routines in C:
>
>calculate 8 dst pixels at once as two longs. then store them into two
>memory addresses. load them as a double and then store them into the two
>consecutive scan-lines..

This only doubles vertically, right???

Mr. Bergmann says that we start with 8 pixels == 8 bytes == 2 longs, and we
get out 2 doubles == 16 bytes == 16 pixels (assuming we are talking 256
color mode).

In article <alexr-0611951927330001@17.202.12.160>,
Alex Rosenberg <[e-mail]> wrote:
>Solid tip. That's one of
the first things we've shown people in the Game
>Kitchens. I'll additionally point out that the doubling routine can make
>use of the rlwimi instruction to perform the byte swizzling. Note that CW7

Why do you need to swizzle bytes?
Are you using this for horizontal doubling??  How does this work?

In article <[e-mail]>,
Robert Barris <[e-mail]> wrote:
>As an aside, the key reason this technique works so well is that the writes
>which are done to the temporary 8-byte variable generally don't cause any
>memory traffic - they hit in the L1 cache (at least they do after the
>first such access) and don't go off-chip (writeback cache is Good). Four
>bytes in from DRAM, 16 bytes out (a pair of doubles), no other external
>memory traffic if it's done right.

Here Mr. Barris 4 bytes in 16 bytes out == double doubling.

Could someone please set me straight about this?

Thanks,
Atman Binstock
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosenberg)
Date: Thu, 09 Nov 1995 18:41:55 -0800
Organization: Hackers Anonymous

In article <[e-mail]>,
[e-mail] (Eric A. Drumbor) wrote:

>     Speaking of Game Kitchens, where can people find more info on Apple's
>Game Kitchens?  Also, are there any transcripts of what went on there?

There aren't any transcripts because most of the real action takes place
one-on-one with each developer. If you're a commercial game developer,
then contact Evangelism to find out how you might get assstance with
developing your products.

- -------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: [e-mail] - Yoyodyne   -
-  330 Waverley St., Apt B - UUCP:ucbvax!apple!alexr   - Propulsion -
-  Palo Alto, CA 94301     -                           - Systems    -
-  [phone] (Home)   - Nobody is my employer so  - :-)        -
-  [phone] (Work)   - nobody cares what I say.  -            -

+++++++++++++++++++++++++++

>From [e-mail] (Chris Rudolph)
Date: Fri, 10 Nov 1995 13:46:53 -0800
Organization: Motion Works Group Limited

In article <47tk4h$[e-mail]>, [e-mail] (Atman Binstock) wrote:

> >In article <[e-mail]>,
> >[e-mail] (Christoph Bergmann) wrote:
> >
> >here's an interesting and useful one for ppc pixel doubling routines in C:
> >
> >calculate 8 dst pixels at once as two longs. then store them into two
> >memory addresses. load them as a double and then store them into the two
> >consecutive scan-lines..
>
> This only doubles vertically, right???
>
> Mr. Bergmann says that we start with 8 pixels == 8 bytes == 2 longs, and we
> get out 2 doubles == 16 bytes == 16 pixels (assuming we are talking 256
> color mode).
>
> In article <alexr-0611951927330001@17.202.12.160>,
> Alex Rosenberg <[e-mail]> wrote:
> >Solid tip. That's one of
> the first things we've shown people in the Game
> >Kitchens. I'll additionally point out that the doubling routine can make
> >use of the rlwimi instruction to perform the byte swizzling. Note that CW7
>
> Why do you need to swizzle bytes?
> Are you using this for horizontal doubling??  How does this work?
>

The swizzling is needed to handle the 1x1 -> 2x2 conversion.
For example, take 4 pixels that you want to double ( 8-bit data )

AB CD EF 12

This would pixel double to:

AB AB CD CD EF EF 12 12
AB AB CD CD EF EF 12 12

This is what I wrote to handle pixel doubling. It works quite fast, but if
anyone out there has better solutions, that would be cool.

//==============================================================
//  PixelDouble
//
//  This routine doubles pixels for 8-bit data.
//
//  inPixels        ->  4 sequential pixels in a scanline.
//  ioScanline1     ->  Pointer to destination scanline
//  ioScanline2     ->  Pointer to destination scanline + 1
//

asm void PixelDouble( register UInt32 inPixels,
                      register UInt32 *ioScanline1,
                      register UInt32 *ioScanline2 )
{
    rlwimi      r0,r3,0,0,7
    rlwimi      r0,r3,24,8,15
    rlwimi      r0,r3,24,16,23
    rlwimi      r0,r3,16,24,31
    stw         r0,0(r4)
    stw         r0,0(r5)

    rlwimi      r0,r3,16,0,7
    rlwimi      r0,r3,8,8,15
    rlwimi      r0,r3,8,16,23
    rlwimi      r0,r3,0,24,31
    stw         r0,4(r4)
    stw         r0,4(r5)

    blr
}

Later...

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Chris Rudolph
Senior Geek, Technology Works.
Motion Works Group Limited

Internet:  [e-mail]
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Sat, 11 Nov 1995 12:53:34 +1000
Organization: University of Queensland

In article <47tk4h$[e-mail]>, [e-mail] (Atman Binstock) wrote:

> >here's an interesting and useful one for ppc pixel doubling routines in C:
> >
> >calculate 8 dst pixels at once as two longs. then store them into two
> >memory addresses. load them as a double and then store them into the two
> >consecutive scan-lines..
>
> This only doubles vertically, right???

by itself, it doubles horizontally. once u have the float though, u can
append it in two scan-lines at once to double in both directions.

> Mr. Bergmann says that we start with 8 pixels == 8 bytes == 2 longs, and we
> get out 2 doubles == 16 bytes == 16 pixels (assuming we are talking 256
> color mode).

yep. but again, u can easily double this vertically as well.

how it works:
 • grab a long input.
 • individually grab each byte of the input (and)
 • make copies of each, and shift them all to the appropriate pos (shift)
 • put them all back together in two longs (or)
 • store the two longs in memory
 • load them as a float
 • store them in VRAM


> Why do you need to swizzle bytes?
> Are you using this for horizontal doubling??  How does this work?

what the instruction he mentioned did was effectively an shift/and/or
combination.. this beats the seperate shift/and and OR that codewarior
puts out..

> >As an aside, the key reason this technique works so well is that the writes
> >which are done to the temporary 8-byte variable generally don't cause any
> >memory traffic - they hit in the L1 cache (at least they do after the
> >first such access) and don't go off-chip (writeback cache is Good). Four
> >bytes in from DRAM, 16 bytes out (a pair of doubles), no other external
> >memory traffic if it's done right.

> Here Mr. Barris 4 bytes in 16 bytes out == double doubling.

he's talking about using it for vertical and horizontal doubling, so there
is one float out for each scan-line in the pair..


ChrisB

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 11 Nov 1995 05:05:58 GMT
Organization: Helsinki University of Technology

In article <alexr-0911951841550001@17.202.12.160> [e-mail] (Alex Rosenberg) writes:
>In article <[e-mail]>,
>[e-mail] (Eric A. Drumbor) wrote:
>>     Speaking of Game Kitchens, where can people find more info on Apple's
>>Game Kitchens?  Also, are there any transcripts of what went on there?
>
>There aren't any transcripts because most of the real action takes place
>one-on-one with each developer. If you're a commercial game developer,
>then contact Evangelism to find out how you might get assstance with
>developing your products.

It would be nice to take part in a kitchen, but I don't think I'll ever
be able to afford to do it: I already know a few tricks and money is
tight enough as it is. I seem to remember seeing an invitation for one
of the games kitchens and it wasn't cheap by any means.

BTW, is there anything interesting going on in the Cupertino/SF area
next March? I'll be there for about two weeks and wouldn't mind meeting
other games programmers.

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

+++++++++++++++++++++++++++

>From [e-mail] (Kevin Tieskoetter)
Date: 11 Nov 1995 15:33:01 GMT
Organization: Albatross Productions

In article <alexr-0911951841550001@17.202.12.160>
[e-mail] (Alex Rosenberg) writes:

> There aren't any transcripts because most of the real action takes place
> one-on-one with each developer. If you're a commercial game developer,
> then contact Evangelism to find out how you might get assstance with
> developing your products.

The dealings are also confidential - people are baring some of their
trade secrets at such kitchens, which shouldn't be taken lightly.

-kevin

//---------------------------------------------------------------------
   Kevin Tieskoetter / Software Prestidigitator, Specular International
//---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 11 Nov 1995 20:44:03 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Chris Rudolph) writes:
>

> asm void PixelDouble( register UInt32 inPixels,
>                       register UInt32 *ioScanline1,
>                       register UInt32 *ioScanline2 )
> {
>     rlwimi      r0,r3,0,0,7
>     rlwimi      r0,r3,24,8,15
>     rlwimi      r0,r3,24,16,23
>     rlwimi      r0,r3,16,24,31
>     stw         r0,0(r4)
>     stw         r0,0(r5)
>
>     rlwimi      r0,r3,16,0,7
>     rlwimi      r0,r3,8,8,15
>     rlwimi      r0,r3,8,16,23
>     rlwimi      r0,r3,0,24,31
>     stw         r0,4(r4)
>     stw         r0,4(r5)
>
>     blr
> }

Point 1: the middle two rlwimi instructions in each group can be combined.
They have the same shift count, and their masks can be merged into one.

    rlwimi      r0,r3,24,8,15
    rlwimi      r0,r3,24,16,23

becomes

    rlwimi      r0,r3,24,8,23


Point 2: don't use this for expanding directly to the screen.  Screen
memory is uncached, so you want to write 64 bits at a time.


Finally, an actual example: this code expands an entire rectangle.



asm void twobytwo(
    register char *dstbase,
    register u32 dstrowbytes,
    register char *srcbase,
    register u32 srcrowbytes,
    register u32 rows,
    register u32 words)
{
#define srcptr  r9
#define dstptr1 r10
#define dstptr2 r11
#define src     r12
#define dst1    r30
#define dst2    r31
#define dst     fp0

// check for null rects on paranoid principles
    cmpwi   rows,0
    beqlr
    cmpwi   words,0
    beqlr
// we need two nonvolatile registers, so we save them here
    stw     r30,-8(sp)
    stw     r31,-4(sp)
// adjust the pointers for preincrement addressing
    addi    dstbase,dstbase,-8
    addi    srcbase,srcbase,-4
rowloop:
// set up the source and destination pointers
    mr      dstptr1,dstbase
    add     dstptr2,dstbase,dstrowbytes
    mr      srcptr,srcbase
    add     srcbase,srcbase,srcrowbytes
    add     dstbase,dstptr2,dstrowbytes
// we use the counter register for the inner loop
    mtctr   words
wordloop:
// get four source pixels
    lwzu    src,4(srcptr)
// do the horizontal expansion
    rlwinm  dst1,src,0,0,7
    rlwinm  dst2,src,0,24,31
    rlwimi  dst1,src,24,8,23
    rlwimi  dst2,src,8,8,23
    rlwimi  dst1,src,16,24,31
    rlwimi  dst2,src,16,0,7
// move the expanded pixels into a fp register by way of (cached) memory
    stw     dst1,-16(sp)
    stw     dst2,-12(sp)
    lfd     dst,-16(sp)
// put sixteen destination pixels
    stfdu   dst,8(dstptr1)
    stfdu   dst,8(dstptr2)
// end of inner loop
    bdnz    wordloop
// end of outer loop
    cmpwi   rows,1
    addi    rows,rows,-1
    bne     rowloop
// we're done.  restore the saved registers and return
    lwz     r30,-8(sp)
    lwz     r31,-4(sp)
    blr
#undef srcptr
#undef dstptr1
#undef dstptr2
#undef src
#undef dst1
#undef dst
}


+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Sun, 12 Nov 1995 18:22:34 +1000
Organization: -

> This is what I wrote to handle pixel doubling. It works quite fast, but if
> anyone out there has better solutions, that would be cool.

<snipped code>


check this:

it uses less instructions for the 'swizzle' and by using floats it is
faster at moving memory.. if anyone can do better, please mail me.


      lwz      r11,dst1    //scanline #1 addr
      lwz      r12,dst2    // " #2
      lwz      r3,src      // src scanline addr
      lwz      r4,srcEnd   // src scanline addr+rowBytes
      lwz      r5,fff      // a ptr to a float

loop: lwz      r0,0(r3)
      addi  r12,r12,8

      rlwinm   r8,r0,0,0,7
      rlwimi   r8,r0,16,24,31
      rlwimi   r8,r0,24,8,23

      stw     r8,0(r5)

      rlwinm   r8,r0,0,24,31
      rlwimi   r8,r0,16,0,7
      rlwimi   r8,r0,8,8,23

      stw      r8,4(r5)

      addi  r11,r11,8
      lfd      fp0,0(r5)
      addi  r3,r3,4
      stfd  fp0,-8(r11)
      cmplw r3,r4
      stfd  fp0,-8(r12)

      blt+  loop

      frfree;
      blr


ChrisB

+++++++++++++++++++++++++++

>From [e-mail] (Andrew Meggs)
Date: Sun, 12 Nov 1995 17:27:03 GMT
Organization: University of Virginia

> //==============================================================
> //  PixelDouble
> //
> //  This routine doubles pixels for 8-bit data.
> //
> //  inPixels        ->  4 sequential pixels in a scanline.
> //  ioScanline1     ->  Pointer to destination scanline
> //  ioScanline2     ->  Pointer to destination scanline + 1
> //
>
> asm void PixelDouble( register UInt32 inPixels,
>                       register UInt32 *ioScanline1,
>                       register UInt32 *ioScanline2 )
> {
>     rlwimi      r0,r3,0,0,7
>     rlwimi      r0,r3,24,8,15
>     rlwimi      r0,r3,24,16,23
>     rlwimi      r0,r3,16,24,31
>     stw         r0,0(r4)
>     stw         r0,0(r5)
>
>     rlwimi      r0,r3,16,0,7
>     rlwimi      r0,r3,8,8,15
>     rlwimi      r0,r3,8,16,23
>     rlwimi      r0,r3,0,24,31
>     stw         r0,4(r4)
>     stw         r0,4(r5)
>
>     blr
> }
>

How does my version look from a performance standpoint?

   lwzu     r3,4(input_buffer)

//   some stuff to avoid pipeline stalls

   mr       r0,r3
   rlwimi   r0,r0,16,16,31
   rlwimi   r3,r3,16,0,15
   rlwimi   r0,r0,8,8,23
   rlwimi   r3,r3,8,8,23
   stw      r3,0(tempbuf)
   stw      r0,4(tempbuf)

//    would I benefit from some instructions here or is a stall not a problem?

   lfd      fp0,0(tempbuf)

//    would I benefit from some instructions here or is a stall not a problem?

   stfdu    fp0,8(output_line1)
   stfdu    fp0,8(output_line2)

The basic difference is that the 8 rlwimi's become an mr and 5 rlwimi's. And
I've put in a first version of the double moving technique, but I'm not
sure about the performance characteristics of all those loads and stores
right next to each other.

--
_________________________________________________________________________
andrew meggs                                 people who sleep really suck
[e-mail]                http://darwin.clas.virginia.edu/~apm3g/

+++++++++++++++++++++++++++

>From [e-mail] (Bo Lindbergh)
Date: 12 Nov 1995 18:53:33 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In article <[e-mail]> [e-mail] (Andrew Meggs) writes:
>
> And I've put in a first version of the double moving technique, but I'm
> not sure about the performance characteristics of all those loads and
> stores right next to each other.

It doesn't matter in the least as long as you're outputting to screen
memory, since the uncached writes take all the time anyway.  Fortunately,
there's a write queue to smooth out the bumps.


/Bo Lindbergh

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 13 Nov 1995 02:24:06 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Andrew Meggs) writes:
>How does my version look from a performance standpoint?

I don't know...I don't even have a PowerMac, but I do have a suggestion.

>The basic difference is that the 8 rlwimi's become an mr and 5 rlwimi's. And
>I've put in a first version of the double moving technique, but I'm not
>sure about the performance characteristics of all those loads and stores
>right next to each other.

What you should do is interleave the code for two pixel doubling sequences.

What you have now is:

        load undoubled data
        shuffle bytes around
        store to temporary storage
        read it into a floating point register
        store fp to video

What you could do is:

        load first undoubled data
        shuffle bytes around                    load second undoubled data
@loop
        store first bytes to temporary storage  shuffle second undoubled data
        load temp to fp register                keep shuffling
        store fp registers to video             store second bytes to temp
        load new data to first registers        load fp registers
        shuffle bytes around                    store fp to video
        keep shuffling                          load second undoubled data
        goto loop, if you aren't done yet

By mixing interleaving independent instructions to the maximum, you
might be able to double the speed of the doubling loop under optimal
conditions. Video memory speed is probably a more severe limiting
factor anyway.

I think you will stall after the mr and the lfd, because they are followed
immediately by instructions that need the result of the move. That means
that if you do something unrelated in between, you can use the cycles
that would otherwise be stalled.

Not ever having had the pleasure to program the PowerPC in asm, this is all
from theory (I only have the Motorola/IBM 601 User's Manual). I tend to do
stuff like this even with the 68K...I think the 040 is somewhat pipelined
and it usually doesn't hurt.

I guess a good rule is that if you are doing something with memory, it's
usually possible to pipeline the next instruction if it is not related
to what you were loading from memory.

I hope this makes sense. It's sometimes hard to understand a processor that
sometimes runs code faster when it contains extra NOP instructions... (I would
tend to think that running faster with NOPs wouldn't be something you could
rely on from processor type to processor type even within the same family.)

--
Juri Munkki [e-mail]      There ain't no such thing as a shareware lunch.
http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.

---------------------------

>From [e-mail] (John W. Baxter)
Subject: Std Template Library Book
Date: Sat, 11 Nov 1995 16:40:47 -0800
Organization: Townsend Communications

"C++ Programmer's Guide to the Standard Template Library" by Mark Nelson
was on the shelf at University Bookstore in Seattle today (11/11).  One
copy which was there has crossed the Sound and is now here.

   Pre-reading review:   1 5/8 inches of book; $49.99.

   That's a much better per-book-inch rate than the K&R C second edition.
But not as good as IM: AOCE Application Interface.

    Seriously...a quick thumb-through suggests this is a useful book about
STL (which is a useful part of the Draft Standard).

    --John

--
  "This item is not available because it cannot be removed."
John W. Baxter    Port Ludlow, WA     [e-mail]

---------------------------

>From [e-mail] (CMSngr)
Subject: VBL Syncing Solution and problems.
Date: 15 Nov 1995 09:54:56 -0500
Organization: America Online, Inc. (1-800-827-6364)


Hi!

 So, someone posted something the other day talking about
avoiding "tearing" in a display routine. Whoever this evil
person was set the concept in my mind (I was having tearing
problems) so I wrote the following. The public entry point
is called bmSync() and basically the call blocks until the
retrace manager says we are between refreshes. Forgive any
idiocy in the code, I didn't even know what the VBL manager
was until last night. The Mac's just this hobby you know?

    It seems to work. That having been said, there are two
problems. First, when I attempt to profile an executable
which calls the bmSync routine with the MW profiler, I get
the following: ASSERT: localStackTop <= globals->threadsStack
->frameBuffer && [... blah blah blah ...] profiler.c: 1476
Second, the last commented out line in bmDestroyVBLTask always
fails when uncommented. The return code is -1 which (according
to the processes manual) means that the queue was not found.
Should this worry me? What am I doing wrong. Whassup with
the MW profiler?

    So, here it is. One should feel free to use the code as
one sees fit. It is far from the best code I've ever written.
One note of explanation is that I guarentee that any given
window is fully on one device and I put the GDHandle of that
device in the window user ref for use in the bmSync routine.

Anyway,
-Chris

PS: The mind boggles at what the damned AOL news reader may
do to this. Sorry if it comes out illegible.

/*
 bmapsync.c  (c) Christopher M. Songer 1995
     All Rights Reserved

 Overview: Provides support for the bmSync call which blocks until
     an opportune moment for screen drawing.

*/

#include "bmap.h"
#include "dbg.h"
#include <Retrace.h>


#define SyncImpossible  0x00000001
#define SyncPossible 0x00000002

typedef struct _t_SyncVBLTask SyncVBLTask;
struct _t_SyncVBLTask
{
 struct VBLTask task; // the retrace task control block.
 unsigned int *ptr;  // pointer to the data for the task to use.
};

static pascal void bmVBLTask(
 VBLTaskPtr task
)
/*
 Purpose: Set the retrace is safe flag.

 Returns: nothing.

 Who: songer
*/
{
 **((unsigned int **)(task + 1)) = 1;
}


SyncVBLTask taskblock;
static int bmCreateVBLTask(
 GDHandle device,   // input window pointer.
 unsigned int *ptr,  // input data pointer.
 short *slotout   // output slot number
)
/*
 Purpose: Installs the VLB task for use on the preferred monitor if
    possible.

 Returns: SyncImpossible if VLBTask cannot be installed.
    SyncPossible is VLB task was sucessfully installed.

 Who: songer
*/
{
 AuxDCEHandle whoknows;
 short slot;
 short devref;
 OSErr err;

 taskblock.task.vblAddr = NewVBLProc( bmVBLTask );
 taskblock.task.qType = vType;
 taskblock.task.vblCount = 1;
 taskblock.task.vblPhase = 0;
 taskblock.ptr = ptr;

 devref = (**device).gdRefNum;
 whoknows = (AuxDCEHandle)(GetDCtlEntry( devref ));
 slot = (**whoknows).dCtlSlot;
 *slotout = slot;

 err = SlotVInstall( (QElemPtr)&taskblock.task, slot );
 ASSERT( err == 0 );

 return SyncPossible;
}


static void bmDestroyVBLTask(
 short slot  // input slot number
)
/*
 Purpose: Removes the VBL task from the queue of slot.

 Returns: nothing.

 Who: songer
*/
{
 OSErr err;

 err = SlotVRemove( (QElemPtr)&taskblock.task, slot );
 //ASSERT( err == 0 );
}


void bmSync(
 BMap *bmap  // input bmap pointer.
)
/*
 Purpose: Waits for a moment when blitting to a monitor will not cause
   "tearing"

 Returns: nothing

 Who: songer
*/
{
 volatile unsigned int bmSyncSafe;
 GDHandle device;
 WindowPtr window;
 short slot;

 ASSERT( bmap->type == BmapWindow );

 window = bmap->bmapdata;
 device = (GDHandle)GetWRefCon( window );
 if( device )
 {
  bmSyncSafe = 0;
  if( bmCreateVBLTask( device, &bmSyncSafe, &slot ) == SyncPossible )
  {
   while( !bmSyncSafe )
   {
    ;  // no warnings
   }

   bmDestroyVBLTask( slot );
  }
 }
}

---------------------------

>From [e-mail] (Eli Meir)
Subject: Where to put temp files?
Date: 26 Oct 1995 21:14:42 GMT
Organization: Dept. of Zoology, Univ. of Washington

I am writing a program that creates temporary files as it runs.  I put
these files into the same directory as the program itself.  Some of my
beta-testers have told me that this is a problem when using At Ease, or
when running off of protected networks.  Where should I put temporary
files so that they are safe on any machine (they are in the 100's of KB
range)?  Is there some official place in the system folder or
something, and if so, what commands do I use to find that place?

Thanks very much in advance.

Eli Meir
Dept of Zoology, Univ of Washington
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Thu, 26 Oct 1995 14:55:36 -0700
Organization: Aladdin Systems

In article <46oto2$[e-mail]>,
[e-mail] (Eli Meir) wrote:

>I am writing a program that creates temporary files as it runs.  I put
>these files into the same directory as the program itself.  Some of my
>beta-testers have told me that this is a problem when using At Ease, or
>when running off of protected networks.  Where should I put temporary
>files so that they are safe on any machine (they are in the 100's of KB
>range)?  Is there some official place in the system folder or
>something, and if so, what commands do I use to find that place?
>
>
Use the routine FindFolder to locate the "temporary items folder"
on the volume that the application is running on.

If the folder cannot be created or is not writeable, then use FindFolder
to locate the the "temporary items folder" on the system volume.

If the folder cannot be created or is not writeable, give up :-)

Look in the header file, "Folders.h", or in NIM:Mac Toolbox Essentials, pp 7.54
for a description of FindFolder.
-- Marshall

--
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety." -- Benjamin Franklin
 _Historical Review of Pennsylvania_, 1759

+++++++++++++++++++++++++++

>From Dave Overton <[e-mail]>
Date: Fri, 27 Oct 1995 17:26:30 GMT
Organization: DataStream Imaging Systems, Inc.


IMHO, let the user choose and set a preference. Particularly if the files
are large, they may want to put
them on another drive with more free space. Check PhotoShop's swap file
for example.
Dave Overton

+++++++++++++++++++++++++++

>From [e-mail] (Ed Samuels)
Date: 28 Oct 1995 13:11:40 -0400
Organization: The Pipeline

In article <46oto2$[e-mail]>, Eli Meir writes:

>I am writing a program that creates temporary files as it runs.  I put
>these files into the same directory as the program itself.  Some of my
>beta-testers have told me that this is a problem when using At Ease, or
>when running off of protected networks.  Where should I put temporary
>files so that they are safe on any machine (they are in the 100's of KB
>range)?  Is there some official place in the system folder or
>something, and if so, what commands do I use to find that place?

    All temporary files should be stored in the "Temporary Items" folder on
the root level of the system disk--don't try to look for it, though,
because it's invisible. The only evidence a normal user has that it's there
is that if there are still files in that folder upon startup--if, for
instance, the system crashes while a temporary file is in it--the Finder
puts it into a "Rescued Items" folder inside of the Trash.
    To find the Temporary Items folder in your application, call the
toolbox function FindFolder:

Pascal:    function FindFolder (vRefNum: integer; folderType: OSType;
createFolder: Boolean; var foundVRefNum:integer; var foundDirID: longint):
OSErr;

C:         OSErr FindFolder (short vRefNum, OSType folderType, Boolean
createFolder, short* foundVRefNum, long* foundDirID);

    FindFolder can find just about any of the important folders used by the
system, such as the system folder, the trash, or the temporary items
folder. To find the temporary items folder, use it this way (example in
Pascal):

    err := FindFolder (kOnSystemDisk, kTemporaryFolderType, true,
itsVRefNum, itsDirID);

    kOnSystemDisk means that you want to look for the folder on the current
startup disk; kTemporaryFolderType is a global constant, the value of which
is 'temp', a 4-letter code representing the temporary items folder; true
means that you want to create the folder if it doesn't exist, and
itsVRefNum and itsDirID are variables that you use to store the volume
number and directory of the folder in question. When you create the FSSpec
of your temp file, use this volume number and directory to put the temp
file into the proper directory.


___________________________________
Richard Samuels                :-)
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Samuels)
Date: 28 Oct 1995 19:43:00 -0400
Organization: The Pipeline

 All temporary files should be stored in the "Temporary Items" folder on
the root level of the system disk--don't try to look for it, though,
because it's invisible. The only evidence a normal user has that it's there
is that if there are still files in that folder upon startup--if, for
instance, the system crashes while a temporary file is in it--the Finder
puts it into a "Rescued Items" folder inside of the Trash.
 To find the Temporary Items folder in your application, call the toolbox
function FindFolder:

Pascal: function FindFolder (vRefNum: integer; folderType: OSType;
createFolder: Boolean; var foundVRefNum:integer; var foundDirID: longint);

C: OSErr FindFolder (short vRefNum, OSType folderType, Boolean
createFolder, short* foundVRefNum, long* foundDirID);

 FindFolder can find the System Folder, any folder inside of it, or just
about any of the important folders used by the system, such as the system
folder, the trash, or the temporary items folder. To find the temporary
items folder, use it this way (example in Pascal):

 err := FindFolder (kOnSystemDisk, kTemporaryFolderType, true, itsVRefNum,
itsDirID);

 kOnSystemDisk means that you want to look for the folder on the current
startup disk; kTemporaryFolderType is a global constant, the value of which
is 'temp', a 4-letter code representing the temporary items folder; true
means that you want to create the folder if it doesn't exist, and
itsVRefNum and itsDirID are variables that you use to store the volume
number and directory of the folder in question. When you create the FSSpec
of your temp file, use this volume number and directory to put the temp
file into the proper directory.

___________________________________
Richard Samuels
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Sun, 29 Oct 1995 21:00:12 -0500
Organization: Tulip Software

In article <46uf64$[e-mail]>, [e-mail] (Ed
Samuels) wrote:

>  All temporary files should be stored in the "Temporary Items" folder on
> the root level of the system disk--don't try to look for it, though,

Please don't always put it on the system disk. I know a lot of
applications do that, and it drives me crazy. I (for one) prefer to
reserve my system disk for system stuff, and I don't leave a lot of empty
space on it for temporary files. Those apps that insist on using the
system disk for temporary files generally fail.

There is a "Temporary Items" folder on every volume. If the user is
creating or using documents associated with the temporary data, a good
rule of thumb is to use the same volume for temporary files. All my apps
do that, and it works out well.

- --------------------
Ed Anson            MediaTree: multimedia outline editor & catalog
Tulip Software
Andover, MA 01810   For details, check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Eli Meir)
Date: 30 Oct 1995 05:36:33 GMT
Organization: Dept. of Zoology, Univ. of Washington

Thanks to everyone for your help.  Putting stuff in the temporary
folder seems to work.

Eli Meir
Dept of Zoology, Univ of Washington
[e-mail]

+++++++++++++++++++++++++++

>From Alex Rosen <[e-mail]>
Date: 30 Oct 1995 21:51:27 GMT
Organization: Pro CD, Inc.

In article <[e-mail]> Ed Anson,
[e-mail] writes:
>There is a "Temporary Items" folder on every volume. If the user is
>creating or using documents associated with the temporary data, a good
>rule of thumb is to use the same volume for temporary files. All my apps
>do that, and it works out well.

This sounds like a good rule, as long as you check for floppies,
read-only directories, and available disk space.

--Alex

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 2 Nov 1995 23:14:53 -0500
Organization: America Online, Inc. (1-800-827-6364)

In article <[e-mail]> Ed Anson,
[e-mail] writes:
>There is a "Temporary Items" folder on every volume. If the user is
>creating or using documents associated with the temporary data, a good
>rule of thumb is to use the same volume for temporary files. All my apps
>do that, and it works out well.

Another rule you should follow is that once you create a temporary file in
the Temporary Items folder, you should open the file and keep it open.
Here's why:

There's a bug in the Finder that can cause files in the Temporary Items
folder to be deleted if the volume is shared with AppleShare server or
File Sharing. The way to prevent that from happening to your files in the
Temporary Items folder is to open the files and keep them open. Open files
cannot be deleted. Another advantage of keeping your files in the
Temporary Items folder open is that when it is time to delete them, you
can always find them - just use the GetFileLocation function in MoreFiles
to get the open file's current location.

Jim Luther
Former keeper of File Manager knowledge...

+++++++++++++++++++++++++++

>From [e-mail] (Mike Noble)
Date: Fri, 3 Nov 1995 15:10:47 GMT
Organization: JYACC

> Ed Anson writes:
>
>There is a "Temporary Items" folder on every volume.

This is not 100% true.  I am a client/server tools developer, and
throughout the development and QA cycle we build applications and
then store them, write protected, on some kind of centralized server,
which is in most cases is accessed via either a UNIX/NFS or Novell
mounted volume.  By default these volumes do not contain a
"Temporary Items" folder.

Mike Noble
JAM for Macintosh Product Development,  JYACC, Inc.


+++++++++++++++++++++++++++

>From [e-mail] (Ed Anson)
Date: Sat, 04 Nov 1995 12:41:49 -0500
Organization: Tulip Software

In article <47c4vt$[e-mail]>, [e-mail] (Jump
Long) wrote:

> In article <[e-mail]> Ed Anson,
> [e-mail] writes:
> >There is a "Temporary Items" folder on every volume. If the user is
> >creating or using documents associated with the temporary data, a good
> >rule of thumb is to use the same volume for temporary files. All my apps
> >do that, and it works out well.
>
> Another rule you should follow is that once you create a temporary file in
> the Temporary Items folder, you should open the file and keep it open.
> Here's why:
   [details deleted]

That's interesting information, and probably a good idea in general.

OTOH: In an application I'm currently working on, I wind up creating a
large number of temporary files. The actual number is undetermined and
essentially unlimited. I suspect that keeping all of them open (I only
need one or two at a time) would place undue strain on system resources.

What are your thoughts on this?

- --------------------
Ed Anson
Tulip Software
Andover, MA 01810   Check out my WWW page:
U.S.A.              <http://www.tiac.net/users/tulip/home.html>

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 14 Nov 1995 04:31:14 -0500
Organization: America Online, Inc. (1-800-827-6364)

Ed Anson wrote:
>OTOH: In an application I'm currently working on, I wind up
>creating a large number of temporary files. The actual number is
>undetermined and essentially unlimited. I suspect that keeping
>all of them open (I only need one or two at a time) would place
>undue strain on system resources.
>
>What are your thoughts on this?

I answered this through email... the shortened answer is:

If you need lots of temporary files and don't want to keep them open, just
create a folder in the Temporary Items folder and put your files there.
Since  your sub-folder's directory ID won't change, if anything moves your
folder, you'll still be able to find it.

- Jim Luther

---------------------------

>From [e-mail] (Kyle Hammond)
Subject: [Q] Volume type information available?
Date: Wed, 8 Nov 1995 15:18:18 GMT
Organization: University of Minnesota

Hi all,

I am writing some code to check all mounted volumes for their type and size.
Currently I use the call PBHGetVInfoSync() and run through the index
until I get an error, as described in THINK Reference.  I have a few
questions about this method however:

a) There does not seem to be any field that tells whether the volume is an
Appleshare volume (on a remote computer).  Currently I check the ioVFSID
field for a non-zero value.  This isn't quite what I want however, since DOS
formatted disks and audio CDs have a non-zero ioVFSID also.  Is there
some other call or field I should look at?

b) The PBHGetVInfoSync() call crashes the system on a Quadra that I tested
it on.  Is there some Gestalt or other call to check if the PBH calls are
available?  And if they're not available how do I check on the volumes?

c) How can I tell if a volume is a CD-ROM, floppy or other removable media?
I would prefer to stay away from SCSI Manager calls if possible.  For floppys
I currently check the ioVDrvInfo field for a value of 1, but it is
possible to connect an external floppy drive that would have another
ioVDrvInfo value (although I haven't seen an external floppy drive for a
long time).

Any and all information pertaining to volume information would be greatly
appreciated.  I have read through everything related to volumes in THINK
Reference; my CD-ROM version of Inside Macintosh is copyright 1995 but
does not even have the PB... calls documented (that I could find)!

Thanks in advance,
Kyle Hammond
[e-mail]
University of Minnesota

+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosen)
Date: Mon, 13 Nov 1995 23:32:37 -0500
Organization: The Internet Access Company

How to detect a CD-ROM drive:
http://dev.info.apple.com/techqa/devices/dev18.html#RTFToC18

How to detect an AppleShare volume:
http://dev.info.apple.com/techqa/files/files01.html#RTFToC1

--Alex

+++++++++++++++++++++++++++

>From [e-mail] (Mark Weinstein)
Date: 15 Nov 95 22:42:04 -0800
Organization: The Microsoft Network (msn.com)

>b) The PBHGetVInfoSync() call crashes the system on a Quadra that
>tested it on.  Is there some Gestalt or other call to check if the
>PBH calls are available?  And if they're not available how do I
>check on the volumes?

NO, dude, you don't need to check for that call at all in _Gestalt.
In fact, I bet a billion dollars that you are simply using the wrong
parameter block; this is the most common error when using that
function, and it will cause your system to crash.  Here is how you
can call it:

void get_vol_info( short vRefNum )
{
   HVolumeParam pb;

   memset( ( void * )&pb, 0, sizeof( pb ) );
   pb.ioVRefNum = vRefNum;
   return( PBHGetVInfoSync( &pb ) );  //may have to typcast, etc..
}

The crucial thing to check w/ your code is the PARAMETER BLOCK you
are using.  If you use a "VolumeParam" and call that function, your
system will crash; the "HVolumeParam"is actually a much larger
structure than VolumeParam, and its the right one to use for that
function.  If you use VolumeParam, you will probably trash values on
your stack, including return addresses from functions you are calling.

Tell me if this works.  MRW.

---------------------------

>From [e-mail] (Michael Trent)
Subject: [Q] _PrimeTime crashes?
Date: Mon, 13 Nov 1995 08:45:44 -0500
Organization: FullFeed Madison ([e-mail])

Here's a question for the MacsBug people. I'm posting it to
c.s.m.programmer.help because it seems like the kind of question a
programmer can answer best.

I've been experiencing a lot of problems with hanging at the _PrimeTime
trap. The computer suddenly freezes, cursor and all. If I press the
interrupt key and drop into MacsBug, it tells me I'm in _PrimeTime. If I
'g'o, everything resumes as normal. It's like _PrimeTime just needed a
little push.

This kind of thing only used to happen in some computer games
(SuperWingCommander, MacDoom), but lately it has been happening all the
time.

I'm not a MacsBug expert. I was wondering if someone doesn't know what
might be causing me to hang at _PrimeTime of hand, maybe someone could
tell me how I could track down the culprit using MacsBug?

Thanks for all your help! I'm really stumped here.

MDT
[e-mail]

--
>>SIG UNDER CONSTRUCTION<<

+++++++++++++++++++++++++++

>From [e-mail] (Michael F. Kamprath)
Date: Mon, 13 Nov 1995 09:45:10 -0800
Organization: <none at all>

In article <[e-mail]>,
[e-mail] (Michael Trent) wrote:

> Here's a question for the MacsBug people. I'm posting it to
> c.s.m.programmer.help because it seems like the kind of question a
> programmer can answer best.
>
> I've been experiencing a lot of problems with hanging at the _PrimeTime
> trap. The computer suddenly freezes, cursor and all. If I press the
> interrupt key and drop into MacsBug, it tells me I'm in _PrimeTime. If I
> 'g'o, everything resumes as normal. It's like _PrimeTime just needed a
> little push.
>

This "phenomenon" has been noticed by many people with a Centris 650 and a
Power PC upgrade card (yes, I've noticed it too). Don't know what causes,
don't know how to fix it, but that "g" command does do the trick.
Irritating, if you ask me.

--
Michael Kamprath
http://www.leonardo.net/kamprath/home.html

---------------------------

End of C.S.M.P. Digest
**********************